데이터 직렬화
2015/08/03
https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/?pnref=story
데이터 직렬화로 속도를 향상... 글이 공유가 걸렸기에
요즘 취미?... 는 아니고 업무의 연장선에서 뚝딱거리고 있는 일에 대한 메모를 남겨봄..
- 분석을 위한 데이터는 대부분 읽기 전용이다. 한 번 읽으면 실시간 수정이 없는 경우가 많다.
- 실시간 분석이라는 것도 사실 어폐가 좀 있다. CE .NET 이 RT를 지원한다고 했을 때... RTOS 하던 사람들의 반응이라는 거슨... 그럼 나도 뭐.. 원빈.. 뭐 그런 느낌적 느낌?
- 빅데이터는 사실 대부분 빅데이터가 아니다. 진짜 빅데이터가 필요한 경우도 드물고, 통계 전문가와 통찰력 있는 분석가가 있다면 빅데이터를 둘러싼 수많은 거대한 잡들이 필요 없는 경우도 많다.
- 결과적으로 빅데이터가 소스인 경우에도 맵리듀스-하이브-임팔라 등의 조합을 통해 데이터를 상당부분 축약할 수 있다. 손실 압축이나 샘플링이 아니라 진짜 리듀스다. 심지어 이렇게 줄인 데이터들은 바이너리도 아니다. 날 텍스트인데도 어마어마*어마어마하게 줄일 수 있다. 그래서 분석 직전의 입력 데이터는 테라니 기가니 하는 데이터가 아니라 이미 수십 수백 메가로 리듀스된 상태다.
- 이렇게 입력 데이터가 생각보다는 스몰이고, 읽기 전용이라고 할 때에는 데이터를 바라보는 관점이 다시 고전적인 방식으로 돌아갈 필요가 있다. 스파크의 RDD는 빅데이터 진영의 무기이지만 결과적으로 읽기 전용의 속성을 이용한다.
- 읽기 전용이 가져오는 장점은 많다. 중간에 데이터의 수정이 없으므로 이미 분석이 완료된 데이터에 전방 피드백(?)을 고려할 필요가 없다.
- 구현 측면에서는 lock을 빼도 된다!!... 자료형을 lock free로 짜도 된다는 이야기다. 아이고 신나. CAS처럼 고도의 기법과는 다른 이야기다.
- 그래서 요즘 해 본 것이 데이터 직렬화다. 입력된 데이터는 고도로 써머리되어 있긴 하지만 아직 나름의 UID 체계를 갖추고 있으며 분석 목적에 맞는 리듀스는 덜 된 상태다.
- RB-TREE의 도입. 트리 밸런싱이 되어 있어서 쏘팅된 데이터가 들어와도 한 놈만 패는 트리가 되지 않는다. 좌측 팔 부터 순회하면 쏘팅되어 있는데 그 비용이 적다. 밸런싱 비용이 적다. 머리가 빠가라도 리눅스 커널등에서 가져올 수 있는 구현체가 있다. STL의 맵도 이걸 쓴다카더라..
- 그리하여 RB-TREE는 데이터 입력용으로 사용한다. 리듀스를 위해서는 써치가 필요하고, 직렬화를 위해서는 순회와 쏘팅에 장점이 있어야 한다.
- 입력이 끝나면 트리에 저장된 내용을 직렬화한다. 이때 시퀀스를 재부여 한다. 이제 버킷 참조(?)/할당(?) 오버헤드가 없는 리얼 O(1) 해시형 자료구조가 된다. .... 배열이라는 뜻이다 .. ;;;
- 직렬화를 하면 캐시 히팅률이 올라간다. 읽기 전용이라 멀티쓰레드 돌려도 아무 문제가 없다. 나눠 계산하기가 쉽다는 뜻이다. 게다가 락프리다. ㅋㅋㅋ. 씨피유 갯수만큼 분석시키면 된다. 캐시 힛팅률만 올라가는게 아니라 파이프도 덜 깨진다. CPU 스톨이 덜 걸리니 이보다 좋을 순 음따. 컴파일러에 따라 다르것지만 어느정도 지가 파이프 덜 깨지게 예측 분기 최대한 쓰도록 이러쿵 저러쿵 해줄 것 같다.
... 아 쓰다가 질렸다... 2부는 나중에...
현재 스코어만. : 싱글쓰레드, 내 머신, 2000만 row, 400메가 원본 데이터, 아이템 300만개, 사용자 400만명의 유사도 계산은 109초. .. 실제로 짜보니 사용자한테 유사 아이템을 낑가 넣어주는 것이 일이더라.... 아직 이게 빠졌음. 트릭에 의한 최적화는 현재 음슴.. 컴파일러 옵션은 O3. 대부분은 직렬화까지의 전처리 단계에서 시간을 소모한다. 직렬화과 완료된 이후의 유사도 연산은 별로 안 씀. 트리에만 의존했던 6월의 작업물과는 딴판이다.
[t:/] is not "technology - root". dawnsea, rss